home *** CD-ROM | disk | FTP | other *** search
- Path: fc.hp.com!news
- From: koren@hpsrk.fc.hp.com (Steve Koren)
- Newsgroups: comp.sys.amiga.misc
- Subject: Re: MUI 3.2
- Date: 14 Feb 1996 13:51:52 -0700
- Organization: HP Fort Collins Site
- Sender: koren@hpsrk.fc.hp.com
- Message-ID: <oj63f8dtytz.fsf@hpsrk.fc.hp.com>
- References: <3118e92b@karkis.canit.se>
- NNTP-Posting-Host: hpsrk.fc.hp.com
- In-reply-to: bornhall@karkis.canit.se's message of 07 Feb 96 12:02:19 CET
- X-Newsreader: Gnus v5.0.9
-
-
- bornhall@karkis.canit.se (Peter Bornhall) wrote:
-
- > khf> 156 Kb. Given what it does (check out the devkit!) I think that's
- >
- > Oh, so MUI consists only of muimaster.library all of a sudden? No,
-
- You're right, its not just muimaster. There's some other stuff. But
- taken together, with its memory allocated at run time, its still chicken
- feed. At least on my system, which isn't a high end one. I run other
- software like Lightwave that routinely allocates more than 30 megabytes
- of RAM. I often run 4 or 5 major applications all at once, with 4 to 5
- big, deep public screens, and have 70 or 80 little tasks running. A few
- hundred K here or there is just down in the noise, compared to the
- features it provides. (And with VMM, the features I'm not using will
- get swapped out and stay swapped out if there is memory pressure
- anyway).
-
- I suppose I can appreciate wanting to save the space on a system that
- only has a few meg of RAM total. But on such a system I think it is not
- unreasonable if you cannot run some popular software.
-
- > the risk of repeating myself, BGUI manages more or less the same in
- > apx 100k.
-
- I don't like BGUI, even it was 10 Kb :-). I have a few programs written
- in it. I just like MUI a lot better. Tastes vary I guess, eh? :-)
-
- > Look, I *KNOW* that it's a lot easier creating a GUI with MUI, but it's NOT
- > the ONLY way to do it you know!
-
- True. But we do need a consistent way, I think. At least eventually.
- I really think AT needs to show some leadership here.
-
- > Face it pal, MUI isn't the "Amiga-saviour" you want it to be. The
- > concept is great, no doubt about that, but first of all we should
- > wait for the next gen Amiga to appear. Then we'll have the
- > horsepower to (hopefully) run things like MUI/BGUI without any
- > slowdown.
-
- Hmm. My system is not "high end" even by Amiga standards (its a bog
- standard 4000/040/25/(16+2)Mb with a GVP Spectrum). MUI 3.2 zips along
- quite nicely for me. When switching between groups with those little
- click-tabs, its like "WHAM!" and the new group is there. You can't even
- *see* it redraw. Its instantaneous - probably 1/20th second or so total
- draw time in all but the most complex of cases. The absolute longest
- delay I've ever seen in a MUI program is one with an extremely complex
- layout with many gadgets. In that case, getting a new window the first
- time takes on the order of 1 second (including the time to load the
- program from HD).
-
- I think MUI runs just fine on today's hardware. It should be even
- better on a high end Amiga, like an 060/50+CV64. I don't see PPC's as a
- necessity here. (I want one for other reasons, mind you :-) ).
-
- > Application consistency?! Between MUI programs, yes, until you start
- > to configure each app to have its own backgrounds, buttons, etc, etc.
- > That's not exactly what I call application consistency.
-
- The ability to configure apps doesn't preclude even visual consistency,
- let alone behavioral or other types.
-
- - steve
-